ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/icon/newsgrp/group93b.txt/000121_icon-group-sender _Sat May 29 02:27:04 1993.msg

Internet Message Format | 1993-06-16 | 4KB

Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Sat, 29 May 1993 09:25:27 MST
Received: by owl.cs.arizona.edu; Sat, 29 May 1993 09:25:26 MST
Date: Sat, 29 May 93 02:27:04 MST
From: [e-mail] (Bill Mitchell)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Comparative Languages (MUMPS?)
Status: R
Errors-To: [e-mail]

I've never worked with MUMPS, but I know of a company that uses it in a
very large medical information system that is very successful.

MUMPS is an old language, dating back to 1965 or so.  MUMPS started as
an operating system, i.e., the machine ran MUMPS, but now usually sits on
top of an operating system.

It's my opinion that MUMPS gets most of its punch from having a memory-managed
string datatype and N-dimensional arrays that can be made persistent.
(Voila -- instant hierarchical database!)  Other factors are that MUMPS is a
pretty simple language and appears to be easy to learn, and that a MUMPS
environment typically provides an edit-run-edit-run cycle (i.e., no link
step).

However, there are some problems.  All my MUMPS knowledge is second hand,
so I hope somebody will correct me if I err.

One problem is that the strings are *not* arbitrary length.  I think the
length defined by the standard is 256 chars, although some implementations
allow up to 512 or perhaps longer.   I don't know if arbitrary characters
(e.g. a NUL) are allowed in strings or not.

Program source is stored as persistent data, which is pretty cool, but
raises problems with configuration management and version control.  For
example, if you replace routine "FOOBAR", *everybody* is then running
with a new version of FOOBAR.

I'm not sure if control structures like "if" and "while" are present in a
traditional form or not.  (For example, I've got a dim recollection that
the clause of a do-loop must fit onto a single line of source.)

A very common idiom is to store values as delimited fields.  For example a
person's name might be represented as "John/J/Smith".  Typically, several
levels of delimiters might be used.  For example, [[1,2],[3,[4,5]]] in Icon
might be represented as the string "/1!2/3!4#5/".  A lot of computational
energy seems to be expended on the assembly and disassembly of such
strings.  [[1,2],[3,[4,5]]] might also be represented as X(1) = "1/2" and
X(2) = "3/4!5" or X(1,1) = 1, X(1,2) = 1, X(2,1) = 3, X(2,1,1) = 4 and
X(2,1,2) = 5.  Those subscripts could have been strings, if so desired.

As far as I know, there's no really schema definition for the database --
the code defines the expected structure of the data.  That means that
you've got to be very careful with documentation of the format of
everything in the database.  If the schema changes, you go through the code
with a fine tooth comb looking for uses of the old schema and rewrite as
appropriate.

MUMPS is typically implemented as an interpreter and some implementations
don't fully analyze source until it is executed.  It's therefore possible to
hit a syntax error in production code.

At one point in time there was a restriction on variable name lengths;
I think it was a five or eight character max.  I don't know if this still
exists or not.

A lot of successful commercial systems written in MUMPS are on the market,
but I think MUMPS might give a person with a recent CS degree a severe case
of culture shock!

    /------------------------------\         /----------------\
   /         Bill Mitchell        \       / 7120 E. Kiva Way \
  /  Mitchell Software Engineering   \O====/ Tucson, AZ, 85715  \
  \ Consulting/Development/Training  /     \   602-577-6431     /
   \  OO Methods/C++/C/Icon/UNIX    /       \   [e-mail]    /
    \------------------------------/         \----------------/